-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: .resolves
and .rejects
expectations
#1300
Conversation
✅ Deploy Preview for vitest-dev ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
What do you mean a function was expected? Promise is expected. Function can be expected for |
@sheremet-va my apologies. I meant to say a function should be allowed to maintain jest compatibility. |
But your example will fail in jest. The error in Jest is:
|
@sheremet-va should it be removed from |
I know that you pulled that line from there. It is there for jest compatibility. As I said, it's a very common pattern that jest supports, and by extension, Vitest. Just remove the line from
Being consistent is behaving the same as Jest does at this point of Vitest development. Maybe later, when we will want to diverge from that we will talk. |
If you really want to help, I would advise adding a type guard inside |
@sheremet-va I see the difference now. To be consistent with Jest, do you want me to just add that type guard to |
We can check inside both. In |
984be7f
to
490989e
Compare
The promise helpers, .resolves and .rejects, were throwing errors when the returned object could not be serialized. Specifically, this would happen when using dynamic imports (e.g. `expect(() => import('./some_module')).resolves`). Additionally, the .resolves helper did not support a function argument even though a function was expected.
490989e
to
4ac985a
Compare
@sheremet-va I just pushed up another related commit. The reason I thought a function was required was due to the specific test I had written. // make sure promise resolves
await expect(Promise.resolve(1)).resolves.not.toThrow() This test caused the following error (hence why I thought it was required originally).
|
.resolves
and .rejects
expectations.resolves
and .rejects
expectations
I think it was created before
|
I wanted to do some changes to your PR, but cannot commit. Can you grant access? Specifically, you didn't cover this cases: await expect((async () => new Error('msg'))()).resolves.not.toThrow() // calls chai assertion
await expect((async () => new Error('msg'))()).resolves.not.toThrow(Error) // calls our assertion
await expect((async () => () => {
throw new Error('msg')
})()).resolves.toThrow()
await expect((async () => () => {
return new Error('msg')
})()).resolves.not.toThrow()
await expect((async () => () => {
return new Error('msg')
})()).resolves.not.toThrow(Error)
})
it('resolves trows chai', async () => {
const assertion = async () => {
await expect((async () => new Error('msg'))()).resolves.toThrow()
}
await expect(assertion).rejects.toThrowError('expected promise to throw an error, but it didn\'t')
})
it('resolves trows jest', async () => {
const assertion = async () => {
await expect((async () => new Error('msg'))()).resolves.toThrow(Error)
}
await expect(assertion).rejects.toThrowError('expected promise to throw an error, but it didn\'t')
}) |
@sheremet-va you should be able to commit now. |
Summary
The promise helpers,
.resolves
and.rejects
, were throwing errors when the returned object could not be serialized. Additionally, the.resolves
helper did not support a function argument even though a function was expected.Examples
1. Promise resolution
With a happy-path test for resolving a promise...
Before
The following error occurs.
After
The test passes.
2. Dynamic imports
With an alternate-path test expecting a dynamic import (promise) to error...
Before
The following error occurs.
After
The test passes.